A module in a module system is associated with a particular name. Modules refer to each other by their respective names. For example, one module may declare a dependency on another module, referring to the depended-upon module by name. However, a module may be renamed. For example, a module may be generated using an automatically assigned name (e.g., assigned by an integrated development environment (IDE)) and may later be renamed using a user-assigned name. As another example, a company may be acquired and subsequently change its module names to reflect the acquisition. Many different reasons for renaming a module exist.
When a module's name changes, consumers of that module (e.g., other modules depending on that module) may break, i.e. cease to function properly, if the consumers are not edited to reference the new module name. Specifically, when a consumer attempts to access a module using its old name, an error may be generated and/or the consumer may encounter errors when attempting to reference the module using its old name. Editing every reference to an old module name, in each of the module's consumers, may be time-consuming, expensive, and/or simply impractical. For example, the developers of a module that is released for use by other developers generally do not have access to edit consuming modules' code.
One approach to renaming a module may be to declare multiple names for that particular module. In other words, the module system may include a single module that can be referenced by multiple names. However, allowing a single module to have multiple names may require the programming environment, compiler, and/or runtime environment to keep track of the multiple names and ensure that references to each of those names resolve to the same module. Thus, allowing a single module to be have multiple names may be resource-intensive and/or error-prone.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.